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Abstract:  This  paper  describes  the  specification,  validation  and  verification  of  system  and  soft¬ 
ware  requirements  using  the  SCR  tabular  method  and  tools.  An  example  is  presented  to  illustrate 
the  SCR  tabular  notation,  and  an  overview  of  each  of  the  ten  tools  in  the  SCR  toolset  is  presented. 
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1  Introduction 

During  the  past  three  decades,  many  formal  methods  have  been  proposed  whose  pur¬ 
pose  is  to  reduce  the  cost  of  constructing  computer  systems  and  to  improve  their  quality. 
Informally,  a  formal  method  is  a  mathematically-based  technique  or  tool  useful  in  devel¬ 
oping  either  hardware  or  software.  Recently,  formal  methods  have  played  a  significantly 
increased  role  in  hardware  design.  More  and  more  companies  that  sell  microprocessors 
and  hardware  chips,  such  as  Intel,  IBM,  and  Motorola,  are  using  formally-based  tools 
such  as  model  checkers  [Clarke  et  al.  (1999)]  and  theorem  provers  (see,  e.g.,  [Shankar 
et  al.  (2001)]),  to  detect  flaws  in  their  designs. 

While  formal  methods  are  applied  less  frequently  in  software  development,  there 
have  been  a  few  recent  cases  in  which  they  have  detected  previously  unknown  defects 
in  real-world  software.  One  prominent  example  is  the  result  of  research  in  Microsoft’s 
SLAM  project  in  which  Ball  and  Rajamani  designed  several  formal  techniques  to  auto¬ 
matically  detect  flaws  in  device  drivers  [Ball  et  al.  (2006)].  In  2006,  Microsoft  released 
the  Static  Driver  Verifier  (SDV)  [Beckert  et  al.  (2006)]  as  part  of  Windows  Vista,  the 
latest  Microsoft  operating  system  —  SDV  uses  the  SLAM  software-model-checking 
engine  to  detect  cases  in  which  device  drivers  linked  to  Vista  violate  one  of  a  set  of 
interface  rules.  Thus  SDV  helps  uncover  defects  in  device  drivers,  a  primary  source  of 
software  bugs  in  Microsoft  applications. 

One  critical  step  in  developing  high-quality  software  is  understanding  and  docu¬ 
menting  the  software  requirements.  Studies  have  shown  that  many  software  defects  can 
be  traced  to  ambiguous,  incomplete,  and  inconsistent  requirements  specifications  and 
that  fixing  these  defects  can  be  very  costly,  especially  when  the  defects  are  detected  late 
in  development.  A  promising  approach  to  constructing  precise,  complete,  and  consis¬ 
tent  requirements  specifications  is  to  represent  the  requirements  in  a  formal  specifica- 
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tion  language  and  to  check  the  specification  for  properties,  such  as  completeness  and 
consistency,  with  formal  analysis  techniques. 

This  article  describes  a  requirements  method  called  Software  Cost  Reduction 
[Heninger  (1980),  Heitmeyer  et  al.  (1996),  Heitmeyer  et  al.  (1998a)],  originally  de¬ 
veloped  by  Parnas,  Heninger,  and  other  researchers  at  the  Naval  Research  Laboratory 
(NRL)  starting  in  the  late  1970s.  A  major  NRL  research  goal  was  to  evaluate  the  utility 
and  scalability  of  software  engineering  principles  by  using  the  principles  to  reconstruct 
software  for  a  practical  system.  The  SCR  method  was  formulated  and  demonstrated  by 
constructing  a  requirements  specification  [Heninger  (1980)]  and  several  design  doc¬ 
uments  [Parnas  and  Clements  (1986)]  for  the  flight  program  of  the  U.S.  Navy’s  A-7 
aircraft. 

SCR  uses  a  tabular  notation  to  represent  the  required  behavior  of  a  software  sys¬ 
tem  to  make  the  requirements  understandable  to  practitioners.  Once  an  SCR  require¬ 
ments  specification  has  been  formulated,  a  set  of  formally  based  tools  called  the  SCR 
Toolset  [Heitmeyer  et  al.  (1998b),  Heitmeyer  et  al.  (2005)]  may  be  used  to  check  the 
consistency,  completeness,  and  correctness  of  the  specification. 

Section  2  reviews  the  semantics  that  underly  SCR,  introduces  the  SCR  tabular  no¬ 
tation,  and  provides  an  example  of  software  requirements  represented  in  the  notation. 
Section  3  describes  how  the  SCR  tools  may  be  used  to  check  the  consistency  and  com¬ 
pleteness  of  requirements  specifications,  to  validate  that  the  specification  captures  the 
intended  behavior,  and  to  verify  (i.e.,  prove),  or  refute,  that  the  specification  satisfies 
critical  application  properties.  It  also  describes  two  recent  tools:  the  SCR  Test  Case 
Generator  and  the  SCR  Code  Generator. 

2  SCR  Formal  Model  and  Tabular  Notation 
2.1  SCR  Formal  Model 

The  objective  of  an  SCR  requirements  specification  is  to  capture  the  required  externally 
visible  behavior  of  a  software  system  precisely  and  unambiguously.  In  an  SCR  spec¬ 
ification  [Heitmeyer  et  al.  (2005),  Heitmeyer  et  al.  (1996)],  monitored  and  controlled 
variables  represent,  respectively,  the  quantities  in  the  system  environment  that  the  sys¬ 
tem  monitors  and  controls.  The  required  system  behavior  is  specified  as  relations  the 
system  must  maintain  between  the  monitored  and  controlled  variables.  To  specify  these 
relations  concisely,  the  SCR  language  provides  two  types  of  auxiliary  variables  — mode 
classes  and  terms —  as  well  as  conditions  and  events. 

A  condition  is  a  predicate  defined  on  a  system  state.  A  basic  event ,  represented  as 
@T(c),  indicates  that  condition  c  changes  from  false  to  true.  The  event  @F(c)  is  defined 
by  @T(->  c).  If  c’s  value  in  the  current  state  is  denoted  c  and  its  value  in  the  next  state 
as  c',  then  the  semantics  of  @T(c)  is  defined  by  ->c  A  c'  and  of  @F(c)  by  c  A  —>d.  A 
conditioned  event ,  denoted  @T(c)  WHEN  d,  adds  a  qualifying  condition  d  to  an  event  and 
has  the  semantics  ~<c  A  d  A  d. 
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In  SCR  specifications,  the  monitored  variables  are  independent  variables,  and  the  mode 
classes,  terms  and  controlled  variables  are  dependent  variables.  SCR  specifications  de¬ 
fine  the  values  of  the  dependent  variables  using  three  types  of  tables:  condition,  event 
and  mode  transition  tables.  Each  term  and  controlled  variable  is  defined  by  either  a  con¬ 
dition  or  an  event  table.  Typically,  a  condition  table  defines  the  variable  values  in  terms 
of  a  mode  class  and  a  set  of  conditions;  an  event  table  defines  variable  values  in  terms 
of  a  mode  class  and  a  set  of  conditioned  events.  A  mode  transition  table  associates  each 
source  mode  and  a  conditioned  event  with  a  destination  mode.  If  the  given  event  occurs 
in  the  source  mode,  then  in  the  next  state  the  system  enters  the  destination  mode 

Two  relations,  NAT  and  REQ  [Parnas  and  Madey  (1995)],  define  the  relationship 
between  the  current  and  next  state  values  of  all  monitored  and  dependent  variables. 
NAT  specifies  the  natural  constraints  on  monitored  and  controlled  variables,  such  as 
constraints  imposed  by  physical  laws  and  the  environment.  REQ  uses  the  SCR  tables  to 
specify  the  required  system  behavior  as  constraints  on  the  dependent  variables.  Given  a 
set  of  dependent  variables,  REQ  is  defined  as  the  conjunction  of  the  functions  defined 
by  the  tables.  In  SCR,  a  state  is  a  function  mapping  a  state  variable  name  to  a  type- 
correct  value;  the  required  system  behavior  is  defined  as  a  state  machine  £  =  (S,  9,  p), 
where  S  is  the  set  of  states,  9  is  a  predicate  on  S  which  defines  the  set  of  initial  states, 
and  p  C  S  x  S  is  the  transition  relation  which  defines  the  allowable  state  transitions. 

2.2  SCR  Requirements  Specification:  Example 

To  illustrate  the  SCR  notation,  this  section  presents  an  SCR  specification  of  a  simple 
control  system  called  the  Safety  Injection  System  (SIS)  [Courtois  and  Parnas  (1993)], 
which  controls  the  water  pressure  level  of  a  nuclear  power  plant’s  cooling  system.  The 
SIS  specification  indicates  how  the  SIS  responds  to  changes  in  its  monitored  variables 
by  changing  a  single  controlled  variable,  which  controls  whether  safety  injection  is  on 
or  off.  The  specification  uses  a  mode  class  (a  set  of  modes)  to  capture  the  history  of 
changes  in  the  monitored  variables.  Although  the  SIS  specification  has  only  one  con¬ 
trolled  variable,  most  SCR  specifications  have  many  controlled  variables.  In  SIS,  the 
system  starts  safety  injection  (if  it  is  not  overridden)  when  water  pressure  drops  below 
a  certain  constant  value  Low.  In  the  SCR  specification  of  SIS,  the  monitored  variables 
— mBlock,  mReset,  and  mWaterPres —  denote  the  states  of  two  switches,  the  block 
and  reset  switches,  and  the  water  pressure  reading;  the  mode  class  mcPressure  indi¬ 
cates  one  of  three  system  modes,  TooLow,  Permitted,  and  High;  the  Boolean  term 
tOverridden  indicates  whether  safety  injection  is  overridden;  and  the  controlled  vari¬ 
able  cSafetylnjection  indicates  whether  safety  injection  is  on  or  off. 

Fig.  1  shows  the  relationship  between  the  SIS  monitored  variables,  the  SIS  modes, 
and  the  single  SIS  controlled  variable.  When,  for  example,  the  system  is  in  the  mode 
TooLow  and  the  water  pressure  reading  changes  from  Low  to  greater  than  or  equal 
to  Low,  the  SIS  mode  changes  to  Permitted;  similarly,  when  SIS  is  in  the  mode 
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Figure  1:  SCR  requirements  specification  of  the  Safety  Injection  System. 


Permitted  and  the  water  pressure  reading  changes  from  a  value  greater  than  or  equal 
to  Low  to  less  than  Low,  the  SIS  mode  changes  to  TooLow. 

Tables  1-3  contain  the  mode  transition,  event,  and  condition  tables  defining  the 
transition  relation  for  the  SIS.  Table  1  contains  a  mode  transition  table  which  defines 
the  mode  transitions  for  the  mode  class  mcPressure.  The  first  row  of  Table  1  states 
that  if  the  system  is  in  mode  TooLow  when  water  pressure  changes  from  less  than 
Low  to  a  value  exceeding  or  equal  to  Low,  the  system  mode  changes  to  Permitted. 
Table  2  contains  an  event  table  defining  the  term  variable  tOverridden.  The  entry 
‘Never’  in  the  event  table  means  that  if  the  system  is  in  the  mode  High,  no  event  can 
cause  tOverridden  to  change  to  true.  The  middle  entry  in  the  second  row  of  Table  2 
states  that  if  the  system  is  in  either  TooLow  or  Permitted  and  the  user  turns  the  Block 
switch  on  when  the  Reset  switch  is  off,  then  the  value  of  tOverridden  in  the  next 
state  is  true.  Table  3  is  a  condition  table  defining  the  value  of  a  controlled  variable 
cSafetylnjection  as  a  state  invariant.  This  invariant  specifies  the  required  relation 
between  the  values  of  cSafetylnjection,  tOverridden,  and  mcPressure. 


Table  1:  Mode  Transition  Table  for  mcPressure. 


Old  Mode 

Event 

New  Mode 

TooLow 

@T(mWaterPres  >  Low) 

Permitted 

Permitted 

@T(mWaterPres  >  Permit) 

High 

Permitted 

@T(mWaterPres  <  Low) 

TooLow 

High 

@T(mWaterPres  <  Permit) 

Permitted 
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Table  2:  Event  Table  for  Overridden. 


Mode  Class 
mcPressure 

Events 

High 

Never 

@F(mcPressure=High) 

TooLow, 

@T(mBlock=0n) 

@T(mcPressure=High) 

Permitted 

WHEN  mReset=0ff 

OR  @T(mReset=0n) 

tOverridden' 

True 

False 

Table  3:  Condition  Table  for  cSaf  etylnjection 


Mode  mcPressure 

Condition 

High,  Permitted 

True 

False 

TooLow 

tOverridden 

NOT  tOverridden 

cSaf etylnjection 

Off 

On 

3  Tools 

The  SCR  Toolset  is  an  integrated  suite  of  tools  supporting  the  SCR  requirements  method 
[Heitmeyer  et  al.  (1998b), Heitmeyer  et  al.  (2005)].  Fig.  2  illustrates  the  tools,  which  in¬ 
clude  a  specification  editor  for  creating  and  modifying  a  requirements  specification,  a 
consistency  checker  for  checking  the  specification  for  well-formedness  (e.g.,  type  cor¬ 
rectness),  a  simulator  for  symbolically  executing  the  system  based  on  the  specification, 
a  model  checker  for  analyzing  the  specification  for  application  properties,  and  a  de¬ 
pendency  graph  browser  for  displaying  variable  dependencies.  In  addition,  the  toolset 
includes  the  TAME  front-end  to  PVS,  an  invariant  generator,  a  property  checker  Salsa, 
a  test  case  generator,  and  a  source  code  generator. 

The  SCR  toolset  has  also  been  evaluated  in  numerous  pilot  projects.  In  one  project, 
researchers  at  NASA’s  IV&V  Facility  used  the  tools  to  detect  ambiguity  and  missing 
assumptions  in  a  software  requirements  specification  for  the  NASA  International  Space 
Station  [Easterbrook  et  al.  (1998)].  In  a  second  project,  engineers  at  Rockwell  Aviation 
used  the  SCR  tools  to  detect  24  errors,  many  of  them  serious,  in  the  requirements  spec¬ 
ification  of  a  flight  guidance  system  [Miller  (1998)].  A  third  of  the  detected  errors  were 
uncovered  in  constructing  the  specification,  a  third  in  running  the  consistency  checker, 
and  the  remaining  third  in  executing  the  the  simulator.  In  a  third  project,  NRL  applied 
the  SCR  tools,  to  the  specification  of  the  Weapons  Control  Panel  (WCP)  of  a  military 
system.  The  tools  uncovered  a  number  of  errors,  including  the  violation  of  a  critical 
safety  property.  Developing  an  SCR  specification  of  WCP  from  the  contractor  specifi¬ 
cation,  using  the  tools  to  detect  specification  errors,  and  building  a  working  prototype 
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Figure  2:  SCR  Toolset. 


of  WCP  from  the  specification  required  only  one  person-month,  thus  demonstrating  the 
utility  and  cost-effectiveness  of  the  SCR  tools. 

More  than  200  organizations  from  academia,  industry,  and  government  have  down¬ 
loaded  the  SCR  tools.  The  tools  have  been  used  in  practice  by  companies  such  as  Lock¬ 
heed  Martin  for  many  years.  Most  recently,  the  tools  were  used  to  provide  evidence 
to  a  certifying  authority  that  a  security-critical  module  of  an  embedded  software  de¬ 
vice  enforces  data  separation  [Heitmeyer  et  al.  (2006)]  and  to  specify  the  requirements 
of  three  safety-critical  software  modules  of  NASA  systems  [Heitmeyer  and  Jeffords 
(2007)]. 

Briefly  described  below  are  the  ten  tools  that  comprise  the  SCR  Toolset.  Four  of  the 
five  tools  shown  in  the  box  at  the  top  of  Fig.  2  have  been  distributed  to  external  orga¬ 
nizations.  The  fifth  tool,  the  model  checker  Spin  [Holzmann  (1991)],  can  be  obtained 
from  Gerard  Holzmann  of  NASA’s  Jet  Propulsion  Laboratory.  For  more  details  about 
the  SCR  Toolset,  see  [Heitmeyer  et  al.  (2005)]. 

3.1  Specification  Editor 

To  create,  modify,  or  display  a  requirements  specification,  the  user  invokes  the  SCR 
specification  editor  [Heitmeyer  et  al.  (2005)].  In  the  SCR  method,  each  specification  is 
organized  into  dictionaries  and  tables.  The  dictionaries  define  the  static  information  in 
the  specification,  such  as  the  names,  values,  and  types  of  variables  and  constants;  the 
user-defined  types;  etc.  The  tables  define  how  the  variables  in  the  specification  change 
in  response  to  changes  in  monitored  variables. 
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3.2  Consistency  Checker 

The  SCR  consistency  checker  [Heitmeyer  et  al.  ( 1996),  Heitmeyer  et  al.  (2005)]  checks 
for  properties  derived  from  the  SCR  requirements  model.  This  tool  detects  syntax  and 
type  errors,  incompleteness  of  variable  definitions,  missing  cases,  unwanted  nondeter¬ 
minism,  and  circular  definitions.  When  an  error  is  detected,  the  consistency  checker 
provides  detailed  feedback  to  help  the  user  correct  the  error.  Consistency  checking  is  a 
form  of  static  analysis.  Since  it  is  accomplished  without  executing  the  specification  or 
performing  a  reachability  analysis,  it  is  more  efficient  than  model  checking.  When  de¬ 
veloping  an  SCR  specification,  the  user  normally  invokes  the  consistency  checker  first 
and  postpones  more  heavy-duty  analysis  such  as  model  checking  until  later  in  devel¬ 
opment.  By  exploiting  the  special  properties  guaranteed  by  consistency  checking,  such 
as  determinism,  the  later  analyses  can  be  more  efficient  [Bharadwaj  and  Heitmeyer 
(1999)]. 

3.3  Simulator 

To  validate  a  specification,  the  user  can  run  the  SCR  simulator  [Heitmeyer  et  al.  (2005)] 
and  analyze  the  results  to  ensure  that  the  specification  captures  the  intended  behav¬ 
ior.  Additionally,  the  user  can  define  invariant  assertions  believed  to  be  true  of  the  re¬ 
quired  system  behavior  and,  using  simulation,  execute  a  series  of  scenarios  to  determine 
whether  any  violate  the  invariants.  To  provide  input  to  the  simulator,  the  user  either  en¬ 
ters  a  sequence  of  input  events  (changes  in  monitored  variables)  or  loads  a  previously 
stored  scenario. 

The  simulator  supports  alternative  front-ends,  tailored  to  particular  application  do¬ 
mains.  For  example,  we  have  developed  a  customized  front-end  for  pilots  to  use  in 
evaluating  an  attack  aircraft  specification  (see  Fig.  3).  Rather  than  clicking  on  mon¬ 
itored  variable  names,  entering  values  for  them,  and  seeing  the  results  of  simulation 
presented  as  variable  values,  a  pilot  clicks  on  visual  representations  of  cockpit  controls 
and  sees  results  presented  on  a  simulated  cockpit  display.  This  front-end  allows  the  pilot 
to  move  out  of  the  world  of  software  requirements  specification  and  into  the  world  of 
attack  aircraft,  where  he  is  the  expert.  Such  an  interface  facilitates  customer  validation 
of  the  specification.  A  customized  front-end,  part  of  the  working  prototype  mentioned 
above,  has  also  been  developed  for  the  WCR 

3.4  Model  Checker 

The  Spin  model  checker  [Holzmann  (1991)]  has  been  integrated  into  the  SCR  toolset 
[Bharadwaj  and  Heitmeyer  (1999)].  After  using  the  tools  described  above  to  develop 
a  formal  requirements  specification,  a  specifier  can  invoke  Spin  within  the  toolset  to 
verify  properties  of  the  specification.  Currently,  we  use  Spin  to  analyze  invariant  prop¬ 
erties.  The  SCR  toolset  automatically  translates  an  SCR  specification  into  Promela ,  the 
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Figure  3:  Customized  simulator  front-end  for  an  avionics  system. 


language  of  Spin.  The  user  can  demonstrate  and  validate  a  property  violation  detected 
by  Spin  with  the  SCR  simulator. 

The  number  of  reachable  states  in  a  state  machine  model  of  a  practical  system  is 
usually  very  large,  sometimes  infinite.  To  make  model  checking  practical,  we  have  de¬ 
veloped  sound  methods  for  deriving  abstractions  from  SCR  specifications,  based  on  the 
property  to  be  analyzed  [Heitmeyer  et  al.  (1998a),  Bharadwaj  and  Heitmeyer  (1999)]. 
The  methods  are  practical:  none  requires  ingenuity  on  the  user’s  part,  and  each  derives 
a  smaller,  more  abstract  model.  The  SCR  abstraction  methods  systematize  techniques 
that  users  of  model  checkers  routinely  apply  but  often  in  ad  hoc  ways.  These  meth¬ 
ods  eliminate  irrelevant  variables  as  well  as  unneeded  detail  from  the  specification.  For 
example,  in  analyzing  a  safety  property  for  WCP,  we  used  our  abstraction  methods  to 
reduce  the  number  of  variables  in  the  specification  from  258  to  55,  and  to  replace  sev¬ 
eral  real-valued  variables  with  discrete  variables,  thus  making  model  checking  feasible 
(by  making  the  state  space  finite). 

3.5  Dependency  Graph  Browser 

One  attribute  of  SCR  requirements  specifications  is  that,  while  they  give  detailed  infor¬ 
mation  about  specific  aspects  of  the  required  system  behavior,  understanding  the  rela¬ 
tionship  between  different  parts  of  a  specification  can  be  difficult,  especially  for  large 
specifications.  To  address  this  problem,  a  Dependency  Graph  Browser  (DGB)  has  been 
developed,  which  represents  the  variable  dependencies  in  a  specification  as  a  directed 


Heitmeyer  C.L.:  Formal  Methods  for  Specifying,  Validating,  and  Verifying  Requirements  615 


graph.  By  examining  this  graph,  a  user  can  detect  errors  such  as  undefined  variables  and 
circular  definitions.  The  user  can  also  invoke  the  DGB  to  display  and  extract  subsets  of 
the  dependency  graph,  e.g.,  the  subgraph  containing  all  variables  on  which  a  selected 
controlled  variable  depends. 

3.6  TAME  Theorem  Prover 

TAME  (Timed  Automata  Modeling  Environment)  [Archer  (2001)],  a  specialized  inter¬ 
face  to  PVS  [Shankar  et  al.  (2001)],  offers  templates  for  specifying  automata  models 
and  customized  strategies  which  implement  high-level  proof  steps  for  proving  automa¬ 
ton  properties  [Archer  et  al.  (2002)].  Initially  developed  for  Timed  Input/Output  Au¬ 
tomata,  TAME  has  been  adapted  to  SCR  by  an  automatic  SCR-to-TAME  translator  and 
by  adding  SCR-specific  strategies  that  prove  many  properties  automatically  and  exhibit 
‘problem  transitions’  for  undischarged  proof  goals. 

3.7  Invariant  Generator 

Algorithms  for  generating  state  invariants  from  SCR  specifications  are  described  in  [Jef¬ 
fords  and  Heitmeyer  (1998)].  Such  invariants  are  useful  as  auxiliary  lemmas  in  proving 
properties  of  SCR  specifications  with  TAME  and  Salsa.  The  SCR  invariant  generator 
generates  invariants  automatically.  The  user  may  choose  which  algorithms  to  apply  and 
may  also  choose  which  tables  (condition,  event,  or  mode  transition  tables)  to  analyze. 

3.8  Salsa  Property  Checker 

The  SCR  property  checker  Salsa  [Bharadwaj  and  Sims  (2000)]  may  be  used  to  check 
SCR  specifications  for  Disjointness  and  Coverage  and  for  satisfaction  of  state  and  tran¬ 
sition  invariants.  Salsa  can  check  the  validity  of  formulas  on  Boolean,  enumerated  and 
integer  variables  restricted  to  Presburger  arithmetic.  It  uses  BDDs  for  analyzing  formu¬ 
las  on  Boolean  and  enumerated  variables  and  an  automata  representation  for  analyzing 
Presburger  arithmetic  formulas. 

3.9  Source  Code  Generator 

While  producing  a  high-quality  requirements  specification  is  crucial,  ultimately  soft¬ 
ware  must  be  implemented  to  satisfy  the  requirements.  A  specification  verified  and 
validated  using  the  SCR  tools  provides  a  solid  basis  for  generating  executable  code.  Al¬ 
though  automatically  generating  code  may  be  infeasible  for  some  purposes  (e.g.  code 
that  provides  an  interface  to  a  physical  device),  such  an  approach  is  feasible  for  code 
that  implements  a  program’s  control  logic  and  simple  data  types.  In  such  cases,  the  code 
can  be  automatically  generated  from  an  SCR  requirements  specification.  Recently,  we 
developed  a  grammar  and  a  set  of  semantic  rules  for  the  SCR  notation  and  used  the 


616  Heitmeyer  C.L.:  Formal  Methods  for  Specifying,  Validating,  and  Verifying  Requirements 


APTS  transformational  system  [Paige  (1993)]  to  automatically  generate  C  source  code 
from  an  SCR  requirements  specification  [Leonard  and  Heitmeyer  (2003)].  We  have 
also  developed  a  number  of  techniques  for  improving  the  efficiency  of  automatically 
generated  code  [Rothamelet  al.  (2006)]. 

3.10  Test  Case  Generator 

To  convince  customers  that  the  implementation  is  acceptable  and  to  detect  errors,  the 
software  implementation  must  be  tested.  An  enormous  problem,  however,  is  that  soft¬ 
ware  testing  is  extremely  costly  and  time-consuming.  Current  estimates  are  that  testing 
consumes  between  40%  and  70%  of  the  software  development  effort  [Beckert  et  al. 
(2006)].  We  have  developed  a  prototype  Test  Case  Generator  [Gargantini  and  Heit¬ 
meyer  (1999)]  which  automatically  constructs  a  suite  of  test  cases  from  an  SCR  re¬ 
quirements  specification.  (A  test  case  is  a  sequence  of  monitored  variable  changes, 
each  coupled  with  a  set  of  controlled  variable  changes.)  To  ensure  that  the  test  cases 
‘cover’  all  possible  system  behaviors,  our  technique  organizes  the  set  of  possible  sys¬ 
tem  executions  into  equivalence  classes  and  builds  one  or  more  test  cases  for  each  class. 
By  reducing  the  human  effort  needed  to  build  and  run  the  test  cases,  this  tool  should 
reduce  both  the  enormous  cost  and  significant  time  and  human  effort  characteristic  of 
current  software  testing  methods. 

4  Conclusions 

Using  a  language  such  as  SCR  to  specify  software  requirements  has  several  advantages. 
First,  due  to  its  tabular  notation,  developers  find  an  SCR  requirements  specification  rel¬ 
atively  easy  to  understand  and  the  SCR  notation  relatively  easy  to  apply  in  formulating 
requirements.  Second,  due  to  SCR’s  formal  semantics,  the  specification  of  the  required 
behavior  is  both  unambiguous  and  precise.  Finally,  due  to  its  formal  state  machine  se¬ 
mantics,  an  SCR  specification  provides  a  sound  basis  for  using  formal  techniques  and 
tools  to  check  the  specifications  for  properties  of  interest.  Like  the  SCR  notation,  the 
SCR  tools  are  designed  for  software  developers  who  lack  advanced  mathematical  train¬ 
ing  and  theorem  proving  skills.  Hence,  developers  can  use  the  tools  to  perform  relatively 
complex  formal  analyses  of  requirements  specifications.  Given  SCR’s  formal  semantics 
coupled  with  its  user-friendly  design,  the  SCR  language  and  tools  provide  a  practical 
formal  method  for  constructing  a  high  quality  requirement  specification  and  for  using 
that  specification  to  automatically  generate  both  source  code  and  test  cases. 
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